As illustrated in FIG. 1, a large web site, like that maintained by many large companies having a presence on the world wide web (www) of the Internet, is often implemented as a network of web pages distributed across multiple web servers. Typically, each web server is located on a separate machine. Each server and its associated set of pages is a sub-web site.
Generally, each sub-web provides a logically cohesive subset of the site's pages termed a “service”. For example, one server may contain all the pages that make up a company's pre-sales information and that sub-web would be called the “pre-sales service”. Another server may contain all the pages that make up the company's laser printer product support information and that sub-web would be called the “laser printer support service”.
The idea that a site is composed of sub-webs can be applied recursively to a large site maintained by a company. Thus, the site may be composed of a pre-sales sub-web, an e-commerce sub-web, a product support sub-web and many others. The product support sub-web may, in turn, be composed of many sub-webs including a community forum sub-web, subscription service sub-web, trouble shooting trees sub-web, and others.
A problem with this multi-server site architecture is that the web pages have the names of the servers hardcoded in their HTTP links so that there is no convenient way to avoid bad links to an inoperative server. This is known as a “server down” problem since the referencing page includes links to one or more objects resident on an unavailable server. For example, referring to FIG. 1, the HTML for WebPageB might include the following elements:                <a href=“http://WebServerA.hp.com/WebPageC.html”>        Click Here To Visit Web Page C        </a>        <a href=“http://WebServerB.hp.com/WebPageE.html”>        Click Here To Visit Web Page E        </a>        
If the browser user clicks on the “Click Here To Visit Web Page E” label, the browser connects to WebServerB.hp.com and asks it to deliver WebPageE.html. This works fine as long as WebServerB.hp.com is working. If WebServerB.hp.com has crashed, the browser cannot connect to it and will eventually time-out and display an error page like that shown in FIG. 2. The timeout typically takes an inordinate period of time (e.g., several minutes) and the error message received is considered by most users to be both unfriendly and uninformative.
Instead of allowing the browser to timeout and display its own error page, web site operators would like a solution that redirects the browser to a page on some other server that is available. Such a procedure would prevent the browser from delaying recognition of the problems and then, only after a timeout period has expired, displaying an unfriendly error message.
Accordingly, a need exists for a web access method and system in which failure of a server is handled gracefully, including the provision of user-friendly and informative error messages or some other useful information.